ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group97b.txt/000137_icon-group-sender _Fri Dec 12 07:44:29 1997.msg

Internet Message Format | 2000-09-20 | 4KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id HAA07416
    for <[e-mail]>; Fri, 12 Dec 1997 07:44:29 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA11776; Fri, 12 Dec 1997 07:44:28 -0700
Date: Thu, 11 Dec 97 22:18:02 -0500
Message-Id: <[e-mail]>
From: Paul Abrahams <[e-mail]>
To: [e-mail]
Cc: [e-mail] (Paul Abrahams)
Subject: Extensions to `open'
Reply-To: [e-mail]
Errors-To: [e-mail]
Status: RO

I would like to propose a small but very useful extension to Icon: that
it should be possible to open a directory by specifying a "d" option to
the `open' function.

It seems that any extension to Icon ought to satisfy three criteria:
  (1) It provides functionality that isn't easily achieved by other means.
  (2) It is stylistically consistent with the rest of the language and
won't break existing code,.
  (3) For a minor extension, it should take someone familiar with the
implementation no more than half a day to code.  (Testing and debugging,
of course, has to be added on.)

Icon already recognizes the existence of directories by providing the
"chdir" function.  At first glance it would seem that being able to scan
a directory is easy enough with the `system' function: you just call the
system command for the purpose.  But that approach has two difficulties.

It's very awkward to retrieve the output, since `system' returns only an
exit code.  More significantly, the user code depends unnecessarily on
the operating environment: in Unix you use `ls', in DOS/Windows you use
`dir', and in MacOS you use something else again which I don't know.
Yet directory structure is a concept common to all modern operating
systems.  It ought to be possible to read a directory without having to
resort to system-dependent code.

Adding an option letter to the second argument of `open' is clearly
consistent with Icon as it stands.  The associated file would then act
as a generator whose result sequence consists of the names of the files
in the directory.  `read' would produce the next file name in the
directory; `reads' should probably produce an error when called on a
directory (as it does, I believe, when called on an output file).

As to the work involved: although I don't know the actual code, I assume
that it involves going to the place where the option letters are
extracted for `open' and inserting one additional case, together with the
appropriate system call.  It also involves recording the fact that the
file is a directory.  In the code for `read', it involves substituting
the "get next filename" API for the "read line" API; both Unix and DOS
provide such an API.

-------

Then there's another extension, perhaps even more useful but not quite
as straightforward to implement: if `open' is called with a null
argument, it invokes the current system's API for *dynamically*
selecting a file to be opened.  This is the usual dialog that enables a
user to browse the directory structure, looking for the file to be
opened.  I have a hunch that if graphical user interfaces were common in
the days when Ralph was first designing Icon, he would have included
this facility.  It recognizes that programs are now used in far more
interactive environments than they were in the old days.

Paul Abrahams